Conventionally, there is a problem bothering administrators of storage systems. It is how to deploy “enough” resources for all workloads running over the storage system. The storage system may be used in a private network or a cloud service system. For example, if a system accessing storage resources for workloads of email service and ERP (Enterprise Resource Planning) service, a controlling server has to deploy all storage and other resources, such as CPU (Central Processing Unit) share and SSD (Solid State Disk) cache size, well enough such that when workloads applied, workable performances, e.g. IOPS (Input/Output Per Second), are acceptable. In practice, the requirement of acceptance of workload performances is written in a SLA (Service Level Agreement) for the system. If an observed performance is less than the required level in the SLA, the administrator needs to adjust the resources so that the observed performance will meet the required level soon. It may be possible that the administrator assigned permanently many resources for sudden peaks of workloads that rarely occurred to meet SLA requirement, and those resources are usually standing by, but it is a waste and few system can afford it. A smart deployment of resources must be efficient and timely.
A traditional architecture of a resource configurative storage system is illustrated in FIG. 1. The resource configurative storage system is usually operated by a controlling server 1. The controlling server 1 has many modules to conduct resource deployment. For example, the controlling server 1 may have a data analysis module 11 to detect requirements from different workloads and analyze a best configuration of resources for them. The controlling server 1 may further have a rule-base engine 12 to provide rules for the data analysis module 11, and a storage resource management module 13 to process configuration orders from the data analysis module 11. Each configuration order may have different deployment of storage resources 2 (e.g. the number of HDD, SSD and fast SSD in use), computation resource 3 (e.g. CPU share), and network resource 4 (e.g. priority in procedure). Usually, the resource configurative storage system is centralized and may have other auxiliary servers to share work loading from the controlling server 1.
There are several problems encountered by the storage system in operation. First, work loading of the single controlling server 1 usually gets heavy as workloads increase. The storage system may not have a best deployment of resources in time. Even the auxiliary servers co-work to operate the storage system, they may deal with separate groups of resources located in a different place or network. Server co-working is not an easy task. Work off-loading to other servers may not occur as expected. Heavy work loading is not healthy for the servers and may waste more resources. Second, based on different workloads applied, the administrator needs to set up different rules or policies into the rule-base engine 12 for the data analysis module 11 to follow. This job requires a seasoned administrator. Even though, exceptions are often seen, and necessary adjustment of the rules or policies must be done for smooth operation of the storage system. The key point is that the controlling server 1 is not with artificial intelligence and not able to learn how to adjust itself but requiring commands from administrators.
In order to settle the problems mentioned above, a method for deploying storage system resources with learning of workloads applied to the storage system is provided.